FYI, should it be useful when reviewing, this is rendered at https://openid.github.io/rp-metadata-choices/mbj-introspection-revocation.html

Token Introspection was primarily designed to be an RS-facing API, and therefore it's generally not clients that will be calling it. We co-opted client authentication methods because that's the only thing that OAuth defines -- OAuth doesn't really have a good story for RS registration, identification, or authentication. All that said, introspection does explicitly allow introspection of refresh tokens, which are client-held, and allows other types including ID Tokens. These imply that clients could do introspection if they wanted to in some circumstances.

Revocation is a little clearer, in that it's a client-facing API and I think it's reasonable to expect a client to use the same authentication methods for both the token endpoint as other endpoints, including registration.

I think the way we got here is that we built out each of these pieces one at a time and that incremental creep didn't seem bad at the time, but looking back a decade later it's a lot messier and more abstract than it needs to be.